A Complete Selenium Automation Framework is a structured and reusable testing architecture that combines Selenium WebDriver with Java, TestNG, Page Object Model, Data Providers, configuration management, reusable utilities, reporting, logging, screenshots, Maven, cross-browser execution, and CI/CD practices. The goal is to create automation code that is readable, maintainable, scalable, reusable, and suitable for real-world projects.
A well-designed framework separates test cases from page interaction logic, test data, configuration, browser management, utilities, and reporting. Selenium documentation also recommends Page Objects as a way to reduce duplicated code and keep page-specific implementation in one place. :contentReference[oaicite:0]{index=0}
Course Resource: Selenium Training | Register for Selenium Course Demo
A Selenium Automation Framework is a predefined project structure, set of coding standards, reusable components, utilities, and execution mechanisms used to develop and maintain Selenium automation tests.
Instead of writing independent Selenium scripts for every test case, a framework provides common components such as WebDriver management, page classes, test data handling, configuration readers, waits, screenshots, reports, logging, and test execution.
Test Case
|
v
TestNG
|
v
Page Object Model
|
v
Utilities / Driver Factory
|
v
Selenium WebDriver
|
v
Browser
|
v
Web Application
|
v
Assertions
|
v
Reports
Writing simple Selenium scripts is sufficient for learning or small experiments, but large applications may contain hundreds or thousands of test scenarios. A framework provides a consistent way to organize and execute those tests.
| Component | Purpose |
|---|---|
| Selenium WebDriver | Automates browser interactions. |
| Java | Programming language used to implement the framework. |
| TestNG | Test execution, assertions, configuration, grouping, parameters, and parallel execution. |
| Page Object Model | Separates page interaction logic from test logic. |
| Data Provider | Supplies multiple test-data combinations. |
| Driver Factory | Creates and manages WebDriver instances. |
| Configuration Reader | Reads environment and framework configuration. |
| Utility Classes | Provide reusable helper methods. |
| Reporting | Generates execution results. |
| Logging | Records framework and test execution information. |
| Screenshot Utility | Captures screenshots when required. |
| Maven | Manages dependencies and build execution. |
| CI/CD | Automates build and test execution. |
Test Cases
|
v
TestNG Layer
|
v
Page Object Layer
|
+-----------+-----------+
| |
v v
Utility Layer Data Layer
| |
+-----------+-----------+
|
v
Driver Factory
|
v
Selenium WebDriver
|
v
Browser
|
v
Application
|
v
Assertions / Results
|
v
Reports + Screenshots
Selenium WebDriver is the browser automation layer of the framework. It provides APIs for launching browsers, navigating to URLs, locating elements, entering values, clicking elements, handling windows, managing cookies, and interacting with web applications.
WebDriver driver = new ChromeDriver();
driver.get("https://example.com");
driver.findElement(By.id("username")).sendKeys("testuser");
driver.findElement(By.id("password")).sendKeys("password");
driver.findElement(By.id("login")).click();
In a complete framework, this browser creation logic should generally be centralized rather than duplicated in every test class.
TestNG commonly acts as the test execution and test management layer in Java-based Selenium frameworks. It supports test annotations, assertions, groups, parameters, Data Providers, dependencies, listeners, and parallel execution. :contentReference[oaicite:1]{index=1}
import org.testng.annotations.Test;
public class LoginTest {
@Test
public void loginTest() {
System.out.println("Executing Login Test");
}
}
Common TestNG configuration annotations include:
| Annotation | Typical Purpose |
|---|---|
| @BeforeSuite | Runs before the TestNG suite. |
| @BeforeTest | Runs before the configured TestNG test. |
| @BeforeClass | Runs before the first test method in a class. |
| @BeforeMethod | Runs before each test method. |
| @AfterMethod | Runs after each test method. |
| @AfterClass | Runs after test methods in the class. |
| @AfterTest | Runs after the configured TestNG test. |
| @AfterSuite | Runs after the suite. |
Page Object Model (POM) is a design pattern in which application pages or meaningful UI components are represented by classes. These classes contain page-specific locators and operations, while test classes focus primarily on scenarios and validations.
The main benefit is that if the UI changes, page-specific changes can generally be made in the relevant page object rather than throughout every test. :contentReference[oaicite:2]{index=2}
LoginPage
|
+-- username locator
+-- password locator
+-- login button
|
+-- enterUsername()
+-- enterPassword()
+-- clickLogin()
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
public class LoginPage {
private final WebDriver driver;
private final By username =
By.id("username");
private final By password =
By.id("password");
private final By loginButton =
By.id("login");
public LoginPage(WebDriver driver) {
this.driver = driver;
}
public void enterUsername(String value) {
driver.findElement(username).sendKeys(value);
}
public void enterPassword(String value) {
driver.findElement(password).sendKeys(value);
}
public void clickLogin() {
driver.findElement(loginButton).click();
}
public void login(String user, String pass) {
enterUsername(user);
enterPassword(pass);
clickLogin();
}
}
import org.testng.annotations.Test;
public class LoginTest extends BaseTest {
@Test
public void validLoginTest() {
LoginPage loginPage =
new LoginPage(driver);
loginPage.login(
"testuser",
"password"
);
}
}
This structure keeps Selenium locators and page actions inside the page class while the test class focuses on the scenario.
A BaseTest class contains common setup and cleanup functionality shared by multiple test classes.
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
public class BaseTest {
protected WebDriver driver;
@BeforeMethod
public void setUp() {
driver = new ChromeDriver();
driver.manage().window().maximize();
driver.get("https://example.com");
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
A Driver Factory centralizes WebDriver creation. This becomes particularly useful when the framework supports multiple browsers.
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.edge.EdgeDriver;
public class DriverFactory {
public static WebDriver createDriver(String browser) {
switch (browser.toLowerCase()) {
case "chrome":
return new ChromeDriver();
case "firefox":
return new FirefoxDriver();
case "edge":
return new EdgeDriver();
default:
throw new IllegalArgumentException(
"Unsupported browser: " + browser
);
}
}
}
Framework configuration includes values such as application URL, browser name, timeout values, environment name, and other non-secret settings.
A properties file can be used to keep such values outside the Java source code.
browser=chrome
environment=qa
baseUrl=https://qa.example.com
implicitWait=10
explicitWait=15
A reusable configuration reader can load values from a properties file.
import java.io.FileInputStream;
import java.io.IOException;
import java.util.Properties;
public class ConfigReader {
private static final Properties properties =
new Properties();
static {
try {
FileInputStream file =
new FileInputStream(
"src/test/resources/config.properties"
);
properties.load(file);
} catch (IOException e) {
throw new RuntimeException(
"Unable to load configuration", e
);
}
}
public static String get(String key) {
return properties.getProperty(key);
}
}
Real-world applications commonly have environments such as Development, QA, Staging, and Production-like environments. The framework should avoid hard-coding environment-specific URLs throughout test classes.
QA -> https://qa.example.com
STAGE -> https://stage.example.com
PROD -> https://www.example.com
The selected environment can be supplied through configuration or a CI/CD parameter.
Data-driven testing separates test logic from the input data used by the test. TestNG Data Providers are commonly used when the same test needs to run with multiple data sets.
import org.testng.annotations.DataProvider;
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(
String username,
String password) {
LoginPage loginPage =
new LoginPage(driver);
loginPage.login(
username,
password
);
}
This allows one test method to execute against multiple data sets without creating duplicate test methods.
Large frameworks may obtain test data from Excel, CSV, JSON, databases, APIs, or other sources.
| Data Source | Typical Use |
|---|---|
| Excel | Business-managed tabular test data. |
| CSV | Simple tabular data. |
| JSON | Structured application/API test data. |
| Database | Dynamic or large data sets. |
| Properties | Configuration values. |
The utility layer contains reusable methods that do not belong to a specific page.
Explicit waits are useful when an interaction should occur only after a particular condition is satisfied.
import java.time.Duration;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;
public class WaitUtil {
public static void waitForElement(
WebDriver driver,
By locator) {
WebDriverWait wait =
new WebDriverWait(
driver,
Duration.ofSeconds(15)
);
wait.until(
ExpectedConditions.visibilityOfElementLocated(
locator
)
);
}
}
Screenshots are particularly useful when diagnosing failures.
import java.io.File;
import java.io.IOException;
import org.openqa.selenium.OutputType;
import org.openqa.selenium.TakesScreenshot;
import org.openqa.selenium.WebDriver;
public class ScreenshotUtil {
public static String capture(
WebDriver driver,
String fileName) throws IOException {
File source =
((TakesScreenshot) driver)
.getScreenshotAs(OutputType.FILE);
File destination =
new File(
"screenshots/" +
fileName +
".png"
);
source.renameTo(destination);
return destination.getAbsolutePath();
}
}
Assertions verify whether the actual application behavior matches the expected result.
import org.testng.Assert;
Assert.assertEquals(
driver.getTitle(),
"Dashboard"
);
Assert.assertTrue(
driver.getCurrentUrl().contains("dashboard")
);
Assertions normally belong in test code rather than being scattered throughout page objects. Selenium's Page Object guidance specifically recommends keeping test verification in the test layer, with limited page-load validation being an exception. :contentReference[oaicite:3]{index=3}
Reporting provides a readable summary of automation execution. A report can include passed tests, failed tests, skipped tests, execution duration, test names, error details, screenshots, and other diagnostic information.
| Report Information | Purpose |
|---|---|
| Passed Tests | Shows successful executions. |
| Failed Tests | Identifies unsuccessful scenarios. |
| Skipped Tests | Shows tests that were not executed. |
| Duration | Shows execution time. |
| Exception Details | Helps identify failure causes. |
| Screenshots | Provides visual evidence. |
| Logs | Provides execution information. |
Logging provides detailed information about what the framework is doing during execution.
INFO - Starting browser
INFO - Navigating to application
INFO - Opening Login Page
INFO - Entering username
INFO - Clicking Login
INFO - Validating dashboard
INFO - Test completed
Logs are especially helpful when a test fails in a CI/CD environment where direct interactive debugging may not be available.
TestNG listeners can be used to react to test execution events. They are useful for implementing framework-level behavior such as logging, screenshots on failure, reporting integration, and execution tracking.
import org.testng.ITestListener;
import org.testng.ITestResult;
public class TestListener implements ITestListener {
@Override
public void onTestFailure(
ITestResult result) {
System.out.println(
"Test Failed: " +
result.getName()
);
}
@Override
public void onTestSuccess(
ITestResult result) {
System.out.println(
"Test Passed: " +
result.getName()
);
}
}
A common framework feature is automatically capturing a screenshot when a test fails.
@Override
public void onTestFailure(
ITestResult result) {
System.out.println(
"Capturing screenshot for: " +
result.getName()
);
// Screenshot utility can be called here.
}
Maven is commonly used to manage Java project dependencies, compile source code, execute tests, and support CI/CD builds.
mvn clean testA typical Maven project contains a pom.xml file that defines project dependencies and build configuration.
<dependencies>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>YOUR_VERSION</version>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>YOUR_VERSION</version>
<scope>test</scope>
</dependency>
</dependencies>
The exact dependency versions should be selected according to the project's supported Java version and current library compatibility.
TestNG XML can define which test classes should be executed and can also be used for suite-level configuration.
<suite name="AutomationSuite">
<test name="RegressionTests">
<classes>
<class name="tests.LoginTest"/>
<class name="tests.SearchTest"/>
<class name="tests.CheckoutTest"/>
</classes>
</test>
</suite>
TestNG groups allow related tests to be organized and executed selectively.
@Test(groups = {"smoke"})
public void loginTest() {
}
@Test(groups = {"regression"})
public void checkoutTest() {
}
@Test(groups = {"smoke", "regression"})
public void searchTest() {
}
Common groups include:
TestNG parameters can be used for configuration values such as browser, environment, or application URL.
<parameter name="browser" value="chrome"/>import org.testng.annotations.Parameters;
@Parameters("browser")
@Test
public void browserTest(String browser) {
System.out.println(
"Browser: " + browser
);
}
| Feature | DataProvider | @Parameters |
|---|---|---|
| Main Purpose | Multiple test-data sets. | Configuration values. |
| Typical Data | Username, password, products, search terms. | Browser, URL, environment. |
| Repeated Execution | Yes. | Not inherently. |
| Source | Java method or external data. | TestNG XML or related configuration. |
A complete framework should allow tests to run against multiple browsers without changing the test logic.
Chrome
Firefox
Edge
|
v
Driver Factory
|
v
Same Test Cases
|
v
Same Page Objects
The browser can be configured using TestNG parameters, system properties, configuration files, or CI/CD variables.
Parallel execution can reduce total execution time when tests are independent and the framework is designed for concurrency.
<suite
name="ParallelSuite"
parallel="tests"
thread-count="3">
...
</suite>
When Selenium tests run concurrently, WebDriver instances should be isolated per execution thread. Shared mutable browser state can cause test interference.
A ThreadLocal-based driver manager is one approach for maintaining a separate WebDriver instance for each execution thread.
public class DriverManager {
private static final ThreadLocal<WebDriver> driver =
new ThreadLocal<>();
public static void setDriver(
WebDriver webDriver) {
driver.set(webDriver);
}
public static WebDriver getDriver() {
return driver.get();
}
public static void unload() {
driver.remove();
}
}
Start
|
v
Read Configuration
|
v
Create WebDriver
|
v
Open Application
|
v
Create Page Object
|
v
Execute Test
|
v
Perform Selenium Actions
|
v
Validate Result
|
+------ PASS ------+
| |
| v
| Report
|
+------ FAIL ------+
|
v
Screenshot
|
v
Report
|
v
Cleanup
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
public class LoginPage {
private final WebDriver driver;
private final By username =
By.id("username");
private final By password =
By.id("password");
private final By loginButton =
By.id("login");
public LoginPage(WebDriver driver) {
this.driver = driver;
}
public void enterUsername(String value) {
driver.findElement(username)
.sendKeys(value);
}
public void enterPassword(String value) {
driver.findElement(password)
.sendKeys(value);
}
public void clickLogin() {
driver.findElement(loginButton)
.click();
}
public void login(
String usernameValue,
String passwordValue) {
enterUsername(usernameValue);
enterPassword(passwordValue);
clickLogin();
}
}
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
public class BaseTest {
protected WebDriver driver;
@BeforeMethod
public void setup() {
driver = new ChromeDriver();
driver.manage()
.window()
.maximize();
driver.get(
"https://example.com/login"
);
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
import org.testng.Assert;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
public class LoginTest extends BaseTest {
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(
String username,
String password) {
LoginPage loginPage =
new LoginPage(driver);
loginPage.login(
username,
password
);
Assert.assertTrue(
driver.getTitle()
.contains("Dashboard")
);
}
}
SeleniumAutomationFramework/
|
|-- pom.xml
|
|-- testng.xml
|
|-- README.md
|
|-- src/
| |-- main/
| | |-- java/
| | |-- factory/
| | | |-- DriverFactory.java
| | |
| | |-- pages/
| | | |-- LoginPage.java
| | | |-- HomePage.java
| | | |-- SearchPage.java
| | | |-- ProductPage.java
| | | |-- CartPage.java
| | | |-- CheckoutPage.java
| | |
| | |-- utilities/
| | |-- WaitUtil.java
| | |-- ScreenshotUtil.java
| | |-- ConfigReader.java
| | |-- ExcelUtil.java
| | |-- JsonUtil.java
| |
| |-- test/
| |-- java/
| | |-- base/
| | | |-- BaseTest.java
| | |
| | |-- tests/
| | |-- LoginTest.java
| | |-- SearchTest.java
| | |-- CheckoutTest.java
| |
| |-- resources/
| |-- config.properties
| |-- testdata.xlsx
| |-- testdata.json
| |-- testng.xml
|
|-- reports/
|
|-- screenshots/
|
|-- logs/
| Layer | Responsibility |
|---|---|
| Test Layer | Contains test scenarios and assertions. |
| Page Layer | Contains locators and page operations. |
| Driver Layer | Creates and manages WebDriver. |
| Data Layer | Provides test data. |
| Utility Layer | Provides reusable helper operations. |
| Configuration Layer | Manages environment and framework settings. |
| Reporting Layer | Produces execution reports. |
| CI/CD Layer | Automates build and test execution. |
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
public class SearchTest extends BaseTest {
@DataProvider(name = "searchData")
public Object[][] searchData() {
return new Object[][] {
{"Laptop"},
{"Mobile"},
{"Headphones"},
{"Keyboard"}
};
}
@Test(dataProvider = "searchData")
public void searchTest(String keyword) {
SearchPage searchPage =
new SearchPage(driver);
searchPage.search(keyword);
}
}
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
public class SearchPage {
private final WebDriver driver;
private final By searchBox =
By.id("search");
private final By searchButton =
By.id("searchButton");
public SearchPage(WebDriver driver) {
this.driver = driver;
}
public void search(String keyword) {
driver.findElement(searchBox)
.clear();
driver.findElement(searchBox)
.sendKeys(keyword);
driver.findElement(searchButton)
.click();
}
}
A real-world framework can divide an e-commerce flow into reusable page classes.
LoginPage
|
v
HomePage
|
v
ProductPage
|
v
CartPage
|
v
CheckoutPage
|
v
OrderConfirmationPage
Each page can expose business-level operations while hiding low-level Selenium implementation details.
A large page does not always need to be represented by one enormous class. Reusable UI sections such as navigation bars, product cards, menus, or headers can be represented as page components.
HomePage
|
+-- HeaderComponent
+-- NavigationComponent
+-- ProductCard
+-- FooterComponent
This approach can improve reuse when the same component appears on multiple pages. Selenium's documentation also describes page component objects for reusable sections of an application. :contentReference[oaicite:4]{index=4}
Page objects should generally expose meaningful page operations and state information rather than containing the test's expected-result assertions.
String actualTitle =
driver.getTitle();
Assert.assertEquals(
actualTitle,
"Dashboard"
);
This keeps the responsibility clear: page classes model the application, while test classes determine whether the observed result satisfies the test expectation. :contentReference[oaicite:5]{index=5}
Modern web applications often contain dynamic elements. The framework should use stable locators and appropriate synchronization rather than relying on arbitrary sleep statements.
WebDriverWait wait =
new WebDriverWait(
driver,
Duration.ofSeconds(15)
);
wait.until(
ExpectedConditions
.elementToBeClickable(
By.id("submit")
)
).click();
| Locator | Example | Typical Consideration |
|---|---|---|
| ID | By.id("username") | Often simple when stable. |
| Name | By.name("email") | Useful when unique and stable. |
| CSS | By.cssSelector(".login-button") | Powerful and concise. |
| XPath | By.xpath("//button[@id='login']") | Useful for complex relationships. |
| Class Name | By.className("button") | Should be unique enough for the intended element. |
Some frameworks implement controlled retry logic for known transient failures. Retry should not be used to hide genuine product defects.
import org.testng.IRetryAnalyzer;
import org.testng.ITestResult;
public class RetryAnalyzer
implements IRetryAnalyzer {
private int count = 0;
private final int maxRetry = 1;
@Override
public boolean retry(
ITestResult result) {
if (count < maxRetry) {
count++;
return true;
}
return false;
}
}
A useful failure-handling workflow is:
Test Failure
|
v
Listener Detects Failure
|
v
Capture Screenshot
|
v
Write Log
|
v
Attach Evidence to Report
|
v
Developer / QA Investigation
A smoke suite validates critical application functionality after a new build.
<groups>
<run>
<include name="smoke"/>
</run>
</groups>
Typical smoke scenarios may include application launch, login, search, basic navigation, and a critical business transaction.
A regression suite contains broader tests intended to validate that existing functionality continues to work after application changes.
Regression Suite
|
+-- Login
+-- Search
+-- Product
+-- Cart
+-- Checkout
+-- Profile
+-- Orders
+-- Logout
A complete Selenium framework can be executed automatically from a CI/CD pipeline.
Developer Commit
|
v
Source Control
|
v
CI Server
|
v
Maven Build
|
v
TestNG
|
v
Selenium Tests
|
v
Reports
|
v
Build Result
mvn clean testCI systems can also pass environment or browser configuration through build parameters or system properties.
mvn clean test -Dbrowser=chrome -Denv=qaSource control allows the automation team to collaborate, review changes, maintain history, and integrate framework execution with CI/CD.
Developer
|
v
git add
|
v
git commit
|
v
git push
|
v
CI Pipeline
|
v
Automated Tests
A scalable framework can use the same test code against different environments.
Environment = QA
|
v
https://qa.example.com
Environment = STAGE
|
v
https://stage.example.com
The test logic and page objects remain the same while configuration determines the target environment.
Passwords, access tokens, API keys, and other sensitive credentials should not normally be stored as plain text in source-controlled Java classes, properties files, or test data.
Use an appropriate secret-management mechanism for the project and ensure that reports and logs do not expose sensitive values.
A mature framework should avoid duplicating common functionality.
Reusable Components
|
+-- DriverFactory
+-- ConfigReader
+-- WaitUtil
+-- ScreenshotUtil
+-- ExcelUtil
+-- JsonUtil
+-- Logger
+-- ReportManager
+-- TestDataProvider
| Component | Example |
|---|---|
| Page Class | LoginPage.java |
| Test Class | LoginTest.java |
| Utility Class | ScreenshotUtil.java |
| Factory Class | DriverFactory.java |
| Configuration | config.properties |
| Test Suite | testng.xml |
| Data Provider | LoginDataProvider.java |
One Responsibility
|
v
One Layer
|
v
Reusable Component
|
v
Maintainable Framework
For example, the Driver Factory should focus on WebDriver creation rather than also reading Excel files, generating reports, and performing application assertions.
Configuration
|
v
Driver Factory
|
v
WebDriver
|
v
TestNG
|
v
Test Class
|
v
Page Object
|
v
Selenium Actions
|
v
Application
|
v
Assertion
|
+-----------+-----------+
| |
PASS FAIL
| |
v v
Report Screenshot
|
v
Report
|
v
Logs
public class DriverFactory {
public static WebDriver createDriver(
String browser) {
switch (browser.toLowerCase()) {
case "chrome":
return new ChromeDriver();
case "firefox":
return new FirefoxDriver();
case "edge":
return new EdgeDriver();
default:
throw new IllegalArgumentException(
"Unsupported browser: " + browser
);
}
}
}
import org.openqa.selenium.WebDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
public class BaseTest {
protected WebDriver driver;
@BeforeMethod
public void setup() {
driver =
DriverFactory.createDriver("chrome");
driver.manage()
.window()
.maximize();
driver.get(
"https://example.com/login"
);
}
@AfterMethod
public void tearDown() {
if (driver != null) {
driver.quit();
}
}
}
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
public class LoginPage {
private final WebDriver driver;
private final By username =
By.id("username");
private final By password =
By.id("password");
private final By loginButton =
By.id("login");
public LoginPage(WebDriver driver) {
this.driver = driver;
}
public void login(
String usernameValue,
String passwordValue) {
driver.findElement(username)
.sendKeys(usernameValue);
driver.findElement(password)
.sendKeys(passwordValue);
driver.findElement(loginButton)
.click();
}
}
import org.testng.Assert;
import org.testng.annotations.DataProvider;
import org.testng.annotations.Test;
public class LoginTest extends BaseTest {
@DataProvider(name = "loginData")
public Object[][] loginData() {
return new Object[][] {
{"admin", "admin123"},
{"manager", "manager123"},
{"employee", "employee123"}
};
}
@Test(dataProvider = "loginData")
public void loginTest(
String username,
String password) {
LoginPage loginPage =
new LoginPage(driver);
loginPage.login(
username,
password
);
Assert.assertTrue(
driver.getTitle()
.contains("Dashboard")
);
}
}
TestNG
|
+---------------+---------------+
| | |
v v v
LoginTest SearchTest CheckoutTest
| | |
v v v
LoginPage SearchPage CheckoutPage
| | |
+---------------+---------------+
|
v
Driver Factory
|
v
Selenium WebDriver
|
v
Web Browser
|
v
E-Commerce App
|
+--------+--------+
| |
v v
Assertions Reports
|
v
Test Result
A framework should be designed so that adding a new page or test does not require rewriting the existing framework.
Existing Framework
|
+-- Add New Page
|
+-- Add New Test
|
+-- Add New Data
|
+-- Add New Utility
|
+-- Add New Browser
|
v
Existing Framework Continues to Work
It is a structured architecture containing reusable components, standards, utilities, and execution mechanisms for developing and maintaining Selenium automation tests.
POM separates page-specific interaction logic from test logic and helps reduce duplication and improve maintainability.
BaseTest is commonly used for shared test setup and cleanup such as WebDriver initialization and browser termination.
Driver Factory centralizes WebDriver creation and can support different browsers or remote execution.
It is an approach where the same test logic is executed using different sets of input data.
TestNG provides test execution, configuration annotations, assertions, groups, parameters, Data Providers, listeners, and parallel execution capabilities.
Utility classes provide reusable operations such as waits, screenshots, configuration reading, file handling, and test-data processing.
External configuration makes environment and execution settings easier to change without modifying test logic.
Concurrent tests using the same mutable WebDriver instance can interfere with each other and produce unreliable results.
Reporting provides a readable record of test execution, including results and useful failure information.
Screenshots provide visual evidence of the browser state at the time of a failure.
It allows automated tests to run as part of an automated build and delivery pipeline.
DataProvider is mainly used for multiple test-data sets, while @Parameters is commonly used for configuration values.
This keeps verification responsibilities in the test layer while page objects focus on representing page behavior.
Separation of responsibilities, reusable components, centralized configuration, maintainable page objects, isolated driver management, and automated execution contribute to scalability.
| Concept | Purpose |
|---|---|
| Selenium WebDriver | Browser automation. |
| TestNG | Test execution and management. |
| POM | Page interaction abstraction. |
| BaseTest | Common test setup and cleanup. |
| DriverFactory | WebDriver creation. |
| DataProvider | Multiple test-data combinations. |
| ConfigReader | Configuration management. |
| WaitUtil | Synchronization. |
| ScreenshotUtil | Failure evidence. |
| Listener | Test execution event handling. |
| Reports | Execution results. |
| Logs | Execution diagnostics. |
| Maven | Build and dependency management. |
| Git | Source control. |
| CI/CD | Automated build and test execution. |
COMPLETE SELENIUM FRAMEWORK
|
+------------------------+------------------------+
| | |
v v v
Configuration Test Data TestNG
| | |
v v v
ConfigReader DataProvider Test Classes
| |
| v
| Page Objects
| |
+------------+-----------+
|
v
Driver Factory
|
v
Selenium WebDriver
|
v
Browser
|
v
Application
|
+----------------+----------------+
| |
v v
Assertions Listener
|
+----------------+----------------+
| |
v v
Screenshots Logs
| |
+----------------+----------------+
|
v
Reports
|
v
CI/CD Pipeline
A complete Selenium Automation Framework combines Selenium WebDriver, Java, TestNG, Page Object Model, Data Providers, configuration management, Driver Factory, utilities, reporting, logging, screenshots, Maven, source control, cross-browser execution, parallel execution, and CI/CD practices into a structured automation solution.
The most important architectural principle is separation of responsibilities. Test classes should describe scenarios, page classes should model application interactions, utilities should provide reusable operations, the driver layer should manage WebDriver, configuration should manage environment settings, and reporting should communicate execution results.
Page Object Model is particularly valuable because it keeps page-specific implementation in dedicated objects and reduces duplicated interaction code. Selenium's official documentation recommends this pattern for improved maintainability and reduced duplication. :contentReference[oaicite:6]{index=6}
A properly structured framework can grow from a small Selenium project into a larger automation solution supporting multiple applications, browsers, environments, data sources, execution modes, reports, and CI/CD pipelines.
Complete Selenium Automation Framework = Selenium WebDriver + Java + TestNG + POM + Data-Driven Testing + Driver Factory + Utilities + Configuration + Reporting + Logging + Cross-Browser + Parallel Execution + Maven + CI/CD.
Learn more about Selenium automation, Page Object Model, framework architecture, TestNG, reporting, reusable automation design, and related testing concepts:
Final Takeaway: A complete Selenium automation framework should make tests easier to write, execute, understand, debug, maintain, and scale. The combination of reusable page objects, centralized browser management, externalized configuration, data-driven testing, synchronization, reporting, logging, and CI/CD creates a strong foundation for real-world Selenium automation projects.
